home *** CD-ROM | disk | FTP | other *** search
Text File | 1993-09-27 | 28.8 KB | 1,118 lines |
-
-
- Network Working Group Steve Kille, WG Chair
- Internet Draft Ned Freed, Editor
-
-
-
-
-
- Mail Monitoring MIB
-
- 25-Sep-1993
-
-
-
-
-
- Status of this Memo
-
- This document is an Internet Draft. Internet Drafts are working
- documents of the Internet Engineering Task Force (IETF), its Areas, and
- its Working Groups. Note that other groups may also distribute working
- documents as Internet Drafts.
-
- Internet Drafts are valid for a maximum of six months and may be
- updated, replaced, or obsoleted by other documents at any time. It is
- inappropriate to use Internet Drafts as reference material or to cite
- them other than as a "work in progress".
-
-
- Table of Contents
-
- 1 Introduction .................................................... 2
- 2 The SNMPv2 Network Management Framework ......................... 2
- 2.1 Object Definitions ............................................ 2
- 3 Message Flow Model .............................................. 3
- 4 MTA Objects ..................................................... 3
- 5 Definitions ..................................................... 4
- 6 Acknowledgements ................................................ 19
- 7 References ...................................................... 19
- 8 Security Considerations ......................................... 19
- 9 Authors' Addresses .............................................. 19
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Internet Draft Mail Monitoring MIB 25-Sep-1993
-
-
- 1. Introduction
-
- This memo defines an experimental portion of the Management Information
- Base (MIB) for use with network management protocols in the Internet
- community. In particular, this memo extends the basic Network Services
- Monitoring MIB [1] to allow monitoring of Message Transfer Agents
- (MTAs). It may also be used to monitor MTA components within gateways.
-
-
- 2. The SNMPv2 Network Management Framework
-
- The SNMPv2 Network Management Framework consists of four major
- components. They are:
-
- o RFC 1442 which defines the SMI, the mechanisms used for describing
- and naming objects for the purpose of management.
-
- o RFC 1213 defines MIB-II, the core set of managed objects for the
- Internet suite of protocols.
-
- o RFC 1445 which defines the administrative and other architectural
- aspects of the framework.
-
- o RFC 1448 which defines the protocol used for network access to
- managed objects.
-
- The Framework permits new objects to be defined for the purpose of
- experimentation and evaluation.
-
-
- 2.1. Object Definitions
-
- Managed objects are accessed via a virtual information store, termed the
- Management Information Base or MIB. Objects in the MIB are defined
- using the subset of Abstract Syntax Notation One (ASN.1) defined in the
- SMI. In particular, each object type is named by an OBJECT IDENTIFIER,
- an administratively assigned name. The object type together with an
- object instance serves to uniquely identify a specific instantiation of
- the object. For human convenience, we often use a textual string,
- termed the descriptor, to refer to the object type.
-
-
-
-
-
-
-
-
-
-
- Expires 25-Mar-1994 [Page 2]
-
-
-
-
-
- Internet Draft Mail Monitoring MIB 25-Sep-1993
-
-
- 3. Message Flow Model
-
- A general model of message flow inside an MTA has to be presented before
- a MIB can be described. Generally speaking, message flow occurs in four
- steps:
-
- (1) Messages are received by the MTA from User Agents, Message Stores,
- other MTAs, and gateways.
-
- (2) The "next hop" for the each message is determined. This is simply
- the destination the message is to be transmitted to; it may or may
- not be the final destination of the message. Multiple "next hops"
- may exist for a single message (as a result of either having
- multiple recipients or distribution list expansion); this may make
- it necessary to duplicate messages.
-
- (3) Messages are converted into the format that's appropriate for the
- next hop.
-
- (4) Messages are transmitted to the appropriate destination, which may
- be a User Agent, Message Store, another MTA, or gateway.
-
- Storage of messages in the MTA occurs at some point during this process.
- However, it is important to note that storage may occur at different and
- possibly even multiple points during this process. For example, some
- MTAs expand messages into multiple copies as they are received. In this
- case (1), (2), and (3) may all occur prior to storage. Other MTAs store
- messages precisely as they are received and perform all expansions and
- conversions during retransmission processing. So here only (1) occurs
- prior to storage. This leads to situations where, in general, a
- measurement of messages received may not equal a measurement of messages
- in store, or a measurement of messages stored may not equal a
- measurement of messages retransmitted, or both.
-
-
- 4. MTA Objects
-
- If there are one or more MTAs on the host, the following mta group may
- be used to monitor them. Any number of the MTAs on a host may be
- monitored. Each MTA is dealt with as a separate application and has its
- own applTable entry in the Network Services Monitoring MIB.
-
- The MIB described in this document covers only the portion which is
- specific to the monitoring of MTAs. The network service related part of
- the MIB is covered in a separate document [1].
-
-
-
-
-
- Expires 25-Mar-1994 [Page 3]
-
-
-
-
-
- Internet Draft Mail Monitoring MIB 25-Sep-1993
-
-
- 5. Definitions
-
- MTA-MIB DEFINITIONS ::= BEGIN
-
- IMPORTS
- OBJECT-TYPE, experimental, Counter32, Gauge32
- FROM SNMPv2-SMI
- DisplayString, TimeInterval
- FROM SNMPv2-TC
- applIndex, applTCPProtoID, applUDPProtoID
- FROM APPLICATION-MIB;
-
- mta MODULE-IDENTITY
- LAST-UPDATED "9309250000Z"
- ORGANIZATION "IETF Mail and Directory Management Working Group"
- CONTACT-INFO
- " Ned Freed
-
- Postal: Innosoft International, Inc.
- 250 West First Street, Suite 240
- Claremont, CA 91711
- US
-
- Tel: +1 909 624 7907
- Fax: +1 909 621 5319
-
- E-Mail: ned@innosoft.com"
- DESCRIPTION
- "The MIB module describing Message Transfer Agents (MTAs)"
- ::= {experimental 47}
-
- mtaObjects OBJECT IDENTIFIER ::= {mta 1}
-
- mtaTable OBJECT-TYPE
- SYNTAX SEQUENCE OF MtaEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "The table holding information specific to an MTA."
- ::= {mtaObjects 1}
-
-
-
-
-
-
-
-
-
-
- Expires 25-Mar-1994 [Page 4]
-
-
-
-
-
- Internet Draft Mail Monitoring MIB 25-Sep-1993
-
-
- mtaEntry OBJECT-TYPE
- SYNTAX MtaEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "The entry associated with each MTA."
- INDEX {applIndex}
- ::= {mtaTable 1}
-
- MtaEntry ::= SEQUENCE {
- mtaReceivedMessages
- Counter32,
- mtaStoredMessages
- Gauge32,
- mtaTransmittedMessages
- Counter32,
- mtaReceivedVolume
- Counter32,
- mtaStoredVolume
- Gauge32,
- mtaTransmittedVolume
- Counter32,
- mtaReceivedRecipients
- Counter32,
- mtaStoredRecipients
- Gauge32,
- mtaTransmittedRecipients
- Counter32
- }
-
- mtaReceivedMessages OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The number of messages received since MTA initialization."
- ::= {mtaEntry 1}
-
- mtaStoredMessages OBJECT-TYPE
- SYNTAX Gauge32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The total number of messages currently stored in the MTA."
- ::= {mtaEntry 2}
-
-
-
-
-
- Expires 25-Mar-1994 [Page 5]
-
-
-
-
-
- Internet Draft Mail Monitoring MIB 25-Sep-1993
-
-
- mtaTransmittedMessages OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The number of messages transmitted since MTA initialization."
- ::= {mtaEntry 3}
-
- mtaReceivedVolume OBJECT-TYPE
- SYNTAX Counter32
- UNITS "K-octets"
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The total volume of messages received since MTA
- initialization, measured in kilo-octets. This volume should
- include all transferred data that is logically above the mail
- transport protocol level. For example, an SMTP-based MTA
- should use the number of kilo-octets in the message header
- and body, while an X.400-based MTA should use the number of
- kilo-octets of P2 data."
- ::= {mtaEntry 4}
-
- mtaStoredVolume OBJECT-TYPE
- SYNTAX Gauge32
- UNITS "K-octets"
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The total volume of messages currently stored in the MTA,
- measured in kilo-octets. This volume should include all
- stored data that is logically above the mail transport
- protocol level. For example, an SMTP-based MTA should
- use the number of kilo-octets in the message header and
- body, while an X.400-based MTA would use the number of
- kilo-octets of P2 data."
- ::= {mtaEntry 5}
-
-
-
-
-
-
-
-
-
-
-
-
-
- Expires 25-Mar-1994 [Page 6]
-
-
-
-
-
- Internet Draft Mail Monitoring MIB 25-Sep-1993
-
-
- mtaTransmittedVolume OBJECT-TYPE
- SYNTAX Counter32
- UNITS "K-octets"
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The total volume of messages transmitted since MTA
- initialization, measured in kilo-octets. This volume should
- include all transferred data that is logically above the mail
- transport protocol level. For example, an SMTP-based MTA
- should use the number of kilo-octets in the message header
- and body, while an X.400-based MTA should use the number of
- kilo-octets of P2 data."
- ::= {mtaEntry 6}
-
- mtaReceivedRecipients OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The total number of recipients specified in all messages
- received since MTA initialization. Recipients this MTA
- had no responsibility for should not be counted even if
- information about such recipients is available."
- ::= {mtaEntry 7}
-
- mtaStoredRecipients OBJECT-TYPE
- SYNTAX Gauge32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The total number of recipients specified in all messages
- currently stored in the MTA. Recipients this MTA had no
- responsibility for should not be counted."
- ::= {mtaEntry 8}
-
- mtaTransmittedRecipients OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The total number of recipients specified in all messages
- transmitted since MTA initialization. Recipients this MTA
- had no responsibility for should not be counted."
- ::= {mtaEntry 9}
-
-
-
-
-
- Expires 25-Mar-1994 [Page 7]
-
-
-
-
-
- Internet Draft Mail Monitoring MIB 25-Sep-1993
-
-
- -- MTAs typically group inbound reception, queue storage, and
- -- outbound transmission in some way. In the most extreme case
- -- information will be maintained for each different entity that
- -- receives messages and for each entity the MTA stores messages for
- -- and delivers messages to. Other MTAs may elect to treat all
- -- reception equally, all queue storage equally, all deliveries
- -- equally, or some combination of this.
-
- -- In any case, a grouping abstraction is an extremely useful for
- -- breaking down the activities of an MTA. For purposes of labelling
- -- this will be called a "group" in this MIB.
-
- -- Each group contains all the variables needed to monitor all aspects
- -- of an MTA's operation. However, the fact that all groups contain
- -- all possible variables does not imply that all groups must use all
- -- possible variables. For example, a single group might be used to
- -- monitor only one kind of event (inbound processing, outbound
- -- processing, or storage). In this sort of configuration all unused
- -- counters would be inaccessible; e.g., returning either a
- -- noSuchName error (for an SNMPv1 get), or a noSuchInstance
- -- exception (for an SNMPv2 get).
-
- -- Groups are not necessarily mutually exclusive. A given event may
- -- be recorded by more than one group, a message may be seen as
- -- stored by more than one group, and so on. Groups should be all
- -- inclusive, however: if groups are implemented all aspects of an
- -- MTA's operation should be registered in at least one group. This
- -- freedom lets implementors use different sets of groups to
- -- provide differents "views" of an MTA.
-
- -- The possibility of overlap between groups means that summing
- -- variables across groups may not produce values equal to those in
- -- the mtaTable. mtaTable should always provide accurate information
- -- about the MTA as a whole.
-
- -- The term "channel" is often used in MTA implementations; channels
- -- are usually, but not always, equivalent to a group. However,
- -- this MIB does not use the term "channel" because there is no
- -- requirement that an MTA supporting this MIB has to map its
- -- "channel" abstraction one-to-one onto the MIB's group abstration.
-
-
-
-
-
-
-
-
-
-
- Expires 25-Mar-1994 [Page 8]
-
-
-
-
-
- Internet Draft Mail Monitoring MIB 25-Sep-1993
-
-
- mtaGroupTable OBJECT-TYPE
- SYNTAX SEQUENCE OF MtaGroupEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "The table holding information specific to each MTA group."
- ::= {mtaObjects 2}
-
- mtaGroupEntry OBJECT-TYPE
- SYNTAX MtaGroupEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "The entry associated with each MTA group."
- INDEX {applIndex, mtaGroupIndex}
- ::= {mtaGroupTable 1}
-
- MtaGroupEntry ::= SEQUENCE {
- mtaGroupIndex
- INTEGER,
- mtaGroupReceivedMessages
- Counter32,
- mtaGroupRejectedMessages
- Counter32,
- mtaGroupStoredMessages
- Gauge32,
- mtaGroupTransmittedMessages
- Counter32,
- mtaGroupReceivedVolume
- Counter32,
- mtaGroupStoredVolume
- Gauge32,
- mtaGroupTransmittedVolume
- Counter32,
- mtaGroupReceivedRecipients
- Counter32,
- mtaGroupStoredRecipients
- Gauge32,
- mtaGroupTransmittedRecipients
- Counter32,
- mtaGroupOldestMessageStored
- TimeInterval,
- mtaGroupInboundAssociations
- Gauge32,
- mtaGroupOutboundAssociations
-
-
-
-
-
- Expires 25-Mar-1994 [Page 9]
-
-
-
-
-
- Internet Draft Mail Monitoring MIB 25-Sep-1993
-
-
- Gauge32,
- mtaGroupAccumulatedInboundAssociations
- Counter32,
- mtaGroupAccumulatedOutboundAssociations
- Counter32,
- mtaGroupLastInboundActivity
- TimeInterval,
- mtaGroupLastOutboundActivity
- TimeInterval,
- mtaGroupRejectedInboundAssociations
- Counter32,
- mtaGroupFailedOutboundAssociations
- Counter32,
- mtaGroupInboundRejectionReason
- DisplayString,
- mtaGroupOutboundConnectFailureReason
- DisplayString,
- mtaGroupScheduledRetry
- TimeInterval,
- mtaGroupMailProtocol
- OBJECT IDENTIFIER,
- mtaGroupName
- DisplayString
- }
-
- mtaGroupIndex OBJECT-TYPE
- SYNTAX INTEGER (1..2147483647)
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "The index associated with a group for a given MTA."
- ::= {mtaGroupEntry 1}
-
- mtaGroupReceivedMessages OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The number of messages received to this group since MTA
- initialization."
- ::= {mtaGroupEntry 2}
-
-
-
-
-
-
-
-
-
- Expires 25-Mar-1994 [Page 10]
-
-
-
-
-
- Internet Draft Mail Monitoring MIB 25-Sep-1993
-
-
- mtaGroupRejectedMessages OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The number of messages rejected by this group since MTA
- initialization."
- ::= {mtaGroupEntry 3}
-
- mtaGroupStoredMessages OBJECT-TYPE
- SYNTAX Gauge32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The total number of messages currently stored in this
- group's queue."
- ::= {mtaGroupEntry 4}
-
- mtaGroupTransmittedMessages OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The number of messages transmitted by this group since MTA
- initialization."
- ::= {mtaGroupEntry 5}
-
- mtaGroupReceivedVolume OBJECT-TYPE
- SYNTAX Counter32
- UNITS "K-octets"
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The total volume of messages received to this group since
- MTA initialization, measured in kilo-octets. This volume
- should include all transferred data that is logically above
- the mail transport protocol level. For example, an
- SMTP-based MTA should use the number of kilo-octets in the
- message header and body, while an X.400-based MTA should use
- the number of kilo-octets of P2 data."
- ::= {mtaGroupEntry 6}
-
-
-
-
-
-
-
-
-
- Expires 25-Mar-1994 [Page 11]
-
-
-
-
-
- Internet Draft Mail Monitoring MIB 25-Sep-1993
-
-
- mtaGroupStoredVolume OBJECT-TYPE
- SYNTAX Gauge32
- UNITS "K-octets"
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The total volume of messages currently stored in this
- group's queue, measured in kilo-octets. This volume should
- include all stored data that is logically above the mail
- transport protocol level. For example, an SMTP-based
- MTA should use the number of kilo-octets in the message
- header and body, while an X.400-based MTA would use the
- number of kilo-octets of P2 data."
- ::= {mtaGroupEntry 7}
-
- mtaGroupTransmittedVolume OBJECT-TYPE
- SYNTAX Counter32
- UNITS "K-octets"
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The total volume of messages transmitted by this group
- since MTA initialization, measured in kilo-octets. This
- volume should include all transferred data that is logically
- above the mail transport protocol level. For example, an
- SMTP-based MTA should use the number of kilo-octets in the
- message header and body, while an X.400-based MTA should use
- the number of kilo-octets of P2 data."
- ::= {mtaGroupEntry 8}
-
- mtaGroupReceivedRecipients OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The total number of recipients specified in all messages
- received to this group since MTA initialization.
- Recipients this MTA had no responsibility for should not
- be counted."
- ::= {mtaGroupEntry 9}
-
-
-
-
-
-
-
-
-
-
- Expires 25-Mar-1994 [Page 12]
-
-
-
-
-
- Internet Draft Mail Monitoring MIB 25-Sep-1993
-
-
- mtaGroupStoredRecipients OBJECT-TYPE
- SYNTAX Gauge32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The total number of recipients specified in all messages
- currently stored in this group's queue. Recipients this
- MTA had no responsibility for should not be counted."
- ::= {mtaGroupEntry 10}
-
- mtaGroupTransmittedRecipients OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The total number of recipients specified in all messages
- transmitted by this group since MTA initialization.
- Recipients this MTA had no responsibility for should not
- be counted."
- ::= {mtaGroupEntry 11}
-
- mtaGroupOldestMessageStored OBJECT-TYPE
- SYNTAX TimeInterval
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Time since the oldest message in this group's queue was
- placed in the queue."
- ::= {mtaGroupEntry 12}
-
- mtaGroupInboundAssociations OBJECT-TYPE
- SYNTAX Gauge32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The number of current associations to the group, where the
- group is the responder."
- ::= {mtaGroupEntry 13}
-
-
-
-
-
-
-
-
-
-
-
-
- Expires 25-Mar-1994 [Page 13]
-
-
-
-
-
- Internet Draft Mail Monitoring MIB 25-Sep-1993
-
-
- mtaGroupOutboundAssociations OBJECT-TYPE
- SYNTAX Gauge32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The number of current associations to the group, where the
- group is the initiator."
- ::= {mtaGroupEntry 14}
-
- mtaGroupAccumulatedInboundAssociations OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The total number of associations to the group since MTA
- initialization, where the group is the responder."
- ::= {mtaGroupEntry 15}
-
- mtaGroupAccumulatedOutboundAssociations OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The total number of associations from the group since MTA
- initialization, where the group was the initiator."
- ::= {mtaGroupEntry 16}
-
- mtaGroupLastInboundActivity OBJECT-TYPE
- SYNTAX TimeInterval
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Time since the last time that this group had an active
- inbound association for purposes of message reception."
- ::= {mtaGroupEntry 17}
-
- mtaGroupLastOutboundActivity OBJECT-TYPE
- SYNTAX TimeInterval
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Time since the last time that this group had an
- outbound association for purposes of message delivery."
- ::= {mtaGroupEntry 18}
-
-
-
-
-
-
- Expires 25-Mar-1994 [Page 14]
-
-
-
-
-
- Internet Draft Mail Monitoring MIB 25-Sep-1993
-
-
- mtaGroupRejectedInboundAssociations OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The total number of inbound associations the group has
- rejected, since MTA initialization."
- ::= {mtaGroupEntry 19}
-
- mtaGroupFailedOutboundAssociations OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The total number associations where the group was the
- initiator and association establishment has failed,
- since MTA initialization."
- ::= {mtaGroupEntry 20}
-
- mtaGroupInboundRejectionReason OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The failure reason, if any, for the last association this
- group refused to respond to. An empty string indicates that
- the last attempt was successful. If no association attempt
- has been made since the MTA was initializaed the value
- should be 'never'."
- ::= {mtaGroupEntry 21}
-
- mtaGroupOutboundConnectFailureReason OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The failure reason, if any, for the last association attempt
- this group initiated. An empty string indicates that the last
- attempt was successful. If no association attempt has been
- made since the MTA was initializaed the value should be
- 'never'."
- ::= {mtaGroupEntry 22}
-
-
-
-
-
-
-
-
- Expires 25-Mar-1994 [Page 15]
-
-
-
-
-
- Internet Draft Mail Monitoring MIB 25-Sep-1993
-
-
- mtaGroupScheduledRetry OBJECT-TYPE
- SYNTAX TimeInterval
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The time when this group is scheduled to next attempt to
- make an association."
- ::= {mtaGroupEntry 23}
-
- mtaGroupMailProtocol OBJECT-TYPE
- SYNTAX OBJECT IDENTIFIER
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "An identification of the protocol being used by this group.
- For an group employing OSI protocols, this will be the
- Application Context. For Internet applications, the IANA
- maintains a registry of the OIDs which correspond to well-known
- message transfer protocols. If the application protocol is
- not listed in the registry, an OID value of the form
- {applTCPProtoID port} or {applUDProtoID port} are used for
- TCP-based and UDP-based protocols, respectively. In either
- case 'port' corresponds to the primary port number being
- used by the group. applTCPProtoID and applUDPProtoID are
- defined in [1]."
- ::= {mtaGroupEntry 24}
-
- mtaGroupName OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "A descriptive name for the group. If this group connects to
- a single remote MTA this should be the name of that MTA. If
- this in turn is an Internet MTA this should be the domain name.
- For an OSI MTA it should be the string encoded distinguished
- name of the managed object using the format defined in RFC-?.
- For X.400(1984) MTAs which do not have a Distinguished Name,
- the RFC-1327 syntax 'mta in globalid' should be used."
- ::= {mtaGroupEntry 25}
-
-
-
-
-
-
-
-
-
-
- Expires 25-Mar-1994 [Page 16]
-
-
-
-
-
- Internet Draft Mail Monitoring MIB 25-Sep-1993
-
-
- mtaGroupAssociationTable OBJECT-TYPE
- SYNTAX SEQUENCE OF MtaGroupAssociationEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "The table holding information regarding the associations
- for each MTA group."
- ::= {mtaObjects 3}
-
- mtaGroupAssociationEntry OBJECT-TYPE
- SYNTAX MtaGroupAssociationEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "The entry holding information regarding the associations
- for each MTA group."
- INDEX {applIndex, mtaGroupIndex, mtaGroupAssociationIndex}
- ::= {mtaGroupAssociationTable 1}
-
- MtaGroupAssociationEntry ::= SEQUENCE {
- mtaGroupAssociationIndex
- INTEGER
- }
-
- mtaGroupAssociationIndex OBJECT-TYPE
- SYNTAX INTEGER (1..2147483647)
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Reference into association table to allow correlation of
- this group's active associations with the association table."
- ::= {mtaGroupAssociationEntry 1}
-
-
- -- Conformance information
-
- mtaConformance OBJECT IDENTIFIER ::= {mta 2}
-
- mtaGroups OBJECT IDENTIFIER ::= {mtaConformance 1}
- mtaCompliances OBJECT IDENTIFIER ::= {mtaConformance 2}
-
-
-
-
-
-
-
-
-
-
- Expires 25-Mar-1994 [Page 17]
-
-
-
-
-
- Internet Draft Mail Monitoring MIB 25-Sep-1993
-
-
- -- Compliance statements
-
- mtaCompliance MODULE-COMPLIANCE
- STATUS current
- DESCRIPTION
- "The compliance statement for SNMPv2 entities
- which implement the Mail Monitoring MIB."
- MODULE -- this module
- MANDATORY-GROUPS {mtaGroup}
- ::= {mtaCompliances 1}
-
-
- -- Units of conformance
-
- mtaGroup OBJECT-GROUP
- OBJECTS {
- mtaReceivedMessages, mtaStoredMessages,
- mtaTransmittedMessages, mtaReceivedVolume, mtaStoredVolume,
- mtaTransmittedVolume, mtaReceivedRecipients,
- mtaStoredRecipients, mtaTransmittedRecipients, mtaGroupIndex,
- mtaGroupReceivedMessages, mtaGroupRejectedMessages,
- mtaGroupStoredMessages, mtaGroupTransmittedMessages,
- mtaGroupReceivedVolume, mtaGroupStoredVolume,
- mtaGroupTransmittedVolume,
- mtaGroupReceivedRecipients, mtaGroupStoredRecipients,
- mtaGroupTransmittedRecipients,
- mtaGroupOldestMessageStored, mtaGroupInboundAssociations,
- mtaGroupOutboundAssociations,
- mtaGroupAccumulatedInboundAssociations,
- mtaGroupAccumulatedOutboundAssociations,
- mtaGroupLastInboundActivity, mtaGroupLastOutboundActivity,
- mtaGroupRejectedInboundAssociations,
- mtaGroupFailedOutboundAssociations,
- mtaGroupInboundRejectionReason,
- mtaGroupOutboundConnectFailureReason,
- mtaGroupScheduledRetry, mtaGroupMailProtocol, mtaGroupName,
- mtaGroupAssociationIndex}
- STATUS current
- DESCRIPTION
- "A collection of objects providing basic monitoring of MTAs."
- ::= {mtaGroups 1}
-
- END
-
-
-
-
-
-
-
- Expires 25-Mar-1994 [Page 18]
-
-
-
-
-
- Internet Draft Mail Monitoring MIB 25-Sep-1993
-
-
- 6. Acknowledgements
-
- This document is a product of the Mail and Directory Management (MADMAN)
- Working Group. It is based on an earlier MIB designed by S. Kille, T.
- Lenggenhager, D. Partain, and W. Yeong.
-
-
- 7. References
-
- [1] Freed, N., Kille, S., "The Network Services Monitoring MIB",
- Internet Draft, September 7, 1993.
-
-
- 8. Security Considerations
-
- Security issues are not discussed in this memo.
-
-
- 9. Authors' Addresses
-
- Ned Freed, Editor
- Innosoft International, Inc.
- 250 West First Street, Suite 240
- Claremont, CA 91711
- USA
- tel: +1 909 624 7907
- fax: +1 909 621 5319
- email: ned@innosoft.com
-
- Steve Kille, WG Chair
- ISODE Consortium
- The Dome, The Square
- Richmond TW9 1DT
- UK
- tel: +44 81 332 9091
- email: S.Kille@isode.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Expires 25-Mar-1994 [Page 19]
-
-
-